---
id: limits
title: System limits - Temporal Cloud
sidebar_label: Limits
description: This page outlines the limits of the Temporal Cloud system for accounts, namespaces, and programming models, providing key information on user capacity, namespace creation, throughput, certificates, task pollers, retention periods, batch jobs, search attributes, visibility API rate limit, identifier length, gRPC message limits, event
slug: /cloud/limits
toc_max_heading_level: 4
keywords:
  - configuration
  - defaults
  - limits
  - settings
  - temporal cloud
tags:
  - Temporal Cloud
  - Limits
---

This page addresses the limits of the Temporal Cloud system.
Reach out to your account team should you have any questions about these limits.

These limits fall into the following three main categories:

- At the Temporal Cloud [Account level](#account-level)
- At the [Namespace level](#namespace-level)
- Within the [programming model](#programming-model-level) itself

## Account level

The following aspects apply at the Temporal Cloud Account level (per account).

### Users

**How many users can I add?**

By default, 300 users across all Namespaces.

### Namespaces

**How many namespaces can I create?​**

By default, each account is provisioned with ten Namespaces.
As you start using Namespaces by scheduling Workflows, Temporal Cloud automatically raises your allowance.
This automatic adjustment happens whenever all your Namespaces are in use, up to a maximum of 100 Namespaces.
You can request further increases beyond the 100 Namespace limit by opening a [support ticket](/cloud/support#support-ticket).

### Retained Prometheus endpoint data

**How much metrics data does the Prometheus endpoint retain?​**

The Prometheus endpoint retains 30 days of data.

### Supported operators in List Filters

**Which operators aren't supported in Temporal Cloud?**

The `ORDER BY` operator isn't supported in List Filters in Temporal Cloud.

This means that custom ordering of Workflows with Temporal Cloud Visibility isn't possible.
Lists of Workflows are still ordered by a default ordering rule, but be aware that this rule might change.

## Namespace level

The following aspects apply at the Namespace level (per Namespace).

### Throughput

**What is the limit of Actions per second?**

Each Namespace has a rate limit, which is measured in Actions per second (APS).
A Namespace may be throttled when its throughput becomes too high.
Throttling means limiting the rate at which Actions are performed to prevent the Namespace from exceeding its APS limit.

A Namespace's default limit is set at 400 APS and automatically adjusts based on recent usage (over the prior 7 days).
Your throughput limit will never fall below this default value.
You can request this limit be manually raised by opening a [support ticket](/cloud/support#support-ticket).

### Schedules rate limit

Each Namespace has a default [Schedule](/glossary#schedule) rate limit of 10 requests per second (RPS).
If too many Schedules trigger at once, they may be throttled.
Throttling limits the rate at which Schedules create new Workflow Executions, ensuring the Namespace does not exceed its RPS limit.

To avoid throttling, don't schedule all your Workflow Executions to start at the same time (daily, weekly, monthly, etc.).
Every Temporal SDK supports jittering, which adds small random delays to Schedule specifications, helping to reduce load at any specific moment.
Set the `jitter` value to the largest delay you will permit before your Workflow Execution must begin.
This approach uniformly distributes the scheduled Workflow Execution launches through that period and reduces your Schedule Workflow Execution RPS load.

If you need a higher Schedule RPS limit, open a [support ticket](/cloud/support#support-ticket).

### Certificates

**What are the certificate limits?**

Temporal Cloud limits each Namespace to a total of 32 KB or 16 certificates, whichever is reached first.

### Concurrent Task pollers

**Is there a limit to concurrent Task pollers?**

Temporal Cloud limits each Namespace to 5,000 concurrent Task pollers, regardless of whether they are Activity or Workflow Task pollers.

Each SDK offers a way to configure Workers for per-Worker maximum Activity and Workflow Task pollers.
Those values do not affect the global Namespace limit.

### Default Retention Period

**What is the default Retention Period?**

The [Retention Period](/clusters#retention-period) is set per Namespace.

Temporal Cloud sets the default Retention Period to 30 days.
This is configurable in the Temporal Web UI.

[Navigate to your list of Namespaces](https://cloud.temporal.io/namespaces), choose the Namespace you want to update, and select edit:

<div className="tdiw">
  <div className="tditw">
    <p className="tdit">Choose your Namespace and select Edit</p>
  </div>
  <div className="tdiiw" height="462">
    <img
      className="img_ev3q"
      src="/img/cloud-guide/edit-namespace-option.png"
      alt="Choose your Namespace and select Edit"
    />
  </div>
</div>

<div className="tdiw">
  <div className="tditw">
    <p className="tdit">Update the Retention Period</p>
  </div>
  <div className="tdiiw" height="482">
    <img
      className="img_ev3q"
      src="/img/cloud-guide/edit-retention-period.png"
      alt="Update the Retention Period"
    />
  </div>
</div>

You can set the Retention Period between 1 and 90 days.

### Batch jobs

**How many batch jobs can run at a time?**

A Namespace can have just one [Batch job](/cli/batch) running at a time.

Each batch job operates on a maximum of 50 Workflow Executions per second.

### Number of Custom Search Attributes

**How many custom Search Attributes are allowed per Namespace?**

There is a limit to the number of custom Search Attributes per attribute type per Namespace:

| Search Attribute type | Limit |
| --------------------- | ----- |
| Bool                  | 20    |
| Datetime              | 20    |
| Double                | 20    |
| Int                   | 20    |
| Keyword               | 40    |
| KeywordList           | 5     |
| Text                  | 5     |

### Custom Search Attribute names

**What constraints are there for Custom Search Attribute names in Temporal Cloud?**

When creating custom Search Attributes in Temporal Cloud, the attribute names must adhere to the following constraints:

- Maximum characters: 64
- Allowed characters: `[a-zA-Z0-9.,:-_\/ ]`.

For more information on custom Search Attributes see [Custom Search Attributes limits](/visibility#custom-search-attributes).

### Visibility API Rate Limit

**What is the rate limit for requests to the Visibility APIs?**

The rate limit for requests to the Visibility APIs varies, and may be as low as 30 requests per second.
This limit is not configurable.

### Nexus Rate Limit {#nexus-rate-limits}

Nexus requests (such as starting a Nexus Operation or sending a Nexus completion callback) are counted as part of the overall Namespace RPS limit.
If too many Nexus requests are sent at once, they may be throttled, along with other requests to the Namespace.
Throttling limits the rate at which Nexus requests are processed, ensuring the RPS limit isn't exceeded.

You can request this limit be manually raised by [opening a support ticket](https://docs.temporal.io/cloud/support#support-ticket).

:::note

For the target Namespace of a Nexus Endpoint, even though there are no Action results for handling a Nexus Operation itself, the Nexus requests on a target Namespace do count towards the overall RPS limit for the Namespace as a whole.

:::

## Nexus Endpoint level

### Nexus Endpoints limits

**How many Nexus Endpoints can you create?​**

By default, each account is provisioned with 10 Nexus Endpoints.
You can request further increases beyond the initial 10 Endpoint limit by [opening a support ticket](/cloud/support#support-ticket).

## Programming model level

The following aspects apply at the programming model level.
See also: [Self-hosted Temporal Service defaults](/self-hosted-guide/defaults).

### Identifier length limit

**What is the maximum length for identifiers?**

Identifiers, such as Workflow Id, Workflow Type, and Task Queue names, are limited to a maximum length of 1,000 bytes.
Note that Unicode characters may use multiple bytes.

### Per message gRPC limit

**What is the gRPC limit for each message received?**

Each gRPC message received has a limit of 4 MB.
This limit applies to all gRPC endpoints across the Temporal Platform.

### Event History transaction size limit

**What is the size limit for an Event History transaction?**

An Event History transaction encompasses a set of operations such as initiating a new Workflow, scheduling an Activity, processing a Signal, or starting a Child Workflow.
These operations create Events that are then logged in the Event History.
The transaction size limit restricts the total size of Events that can be accommodated within a single transaction.

The size limit for any given [Event History](/workflows#event-history) transaction is 4 MB.
This limit is non-configurable for Temporal Cloud.

**What is the blob size limit for a transaction?**

- **Blob size limit** for Payloads, including Workflow context and each Workflow and Activity argument and return value:
  - The max payload for a single request is 2 MB.
  - The max size limit for any given [Event History](/workflows#event-history) transaction is 4 MB.

This limit is non-configurable for Temporal Cloud.

The [BlobSizeLimitError guide](/troubleshooting/blob-size-limit-error) provides solutions for handling large payloads.

### Per Workflow Execution concurrency limits

**How many incomplete concurrent operations can a Workflow Execution have?**

If a Workflow Execution has 2,000 incomplete Activities, Signals, Child Workflows, or external Workflow Cancellation requests, additional [Commands](/workflows#command) of that type will fail to be applied to that Workflow Execution:

- `ScheduleActivityTask`
- `SignalExternalWorkflowExecution`
- `StartChildWorkflowExecution`
- `RequestCancelExternalWorkflowExecution`

For optimal performance, limit concurrent operations to 500 or fewer.
This reduces Workflow's Event History size and decreases the loading time in the Web UI.

### Per Workflow Execution Signal limit

**What is the limit on the total number of Signals received per Workflow Execution?**

A single Workflow Execution may receive up to 10,000 Signals.
After that limit is reached, no more Signals will be processed for that Workflow Execution.

### Per Workflow Execution Update limits

**What is the maximum number of Updates for a single Workflow Execution?**

A single Workflow Execution can have a maximum of 10 in-flight Updates and 2000 total Updates in History.

### Workflow Execution Event History limits

**What are the limits that apply to the Workflow Execution's Event History?**

As a precautionary measure, a Workflow Execution's Event History is limited to 51,200 Events or 50 MB.
It warns you after 10,240 Events or 10 MB.
This limit applies to all Temporal Workflow Executions, whether on Temporal Cloud or other deployments.
Read more about [Temporal Workflow Execution limits](/workflows#limits) on the [Temporal Workflow](/workflows) documentation page.

### Per Workflow Nexus Operation limits {#per-workflow-nexus-operation-limits}

**What is the maximum number of Nexus Operations that can be started from a single Workflow Execution?**

A single Workflow Execution can have a maximum of 30 in-flight Nexus Operations and 30 total Nexus Operations (as Public Preview does not remove completed Nexus Operations from mutable state).
After the Workflow Execution reaches that limit, it won't process any further Nexus Operations.

See the Nexus Encyclopedia entry for [additional details](/workflows#workflow-execution-nexus-operation-limits).

### Nexus Operation request timeout {#nexus-operation-request-timeout}

**What is the context deadline timeout for a Nexus handler to process a Nexus start or cancel request?**

Less than 10 seconds is the maximum duration for a Nexus handler to process a single Nexus start or cancel request.

The timeout is measured from the calling History Service and the request must go through matching, so the available time for a handler to respond is often much less than 10 seconds.
Handlers should observe the context deadline and ensure they don't exceed it.
This includes fully processing a synchronous Nexus operation and starting an asynchronous Nexus operation, for example one that starts a Workflow.

If a Nexus handler doesn’t process a start or cancel request within 10 seconds, it will receive a context deadline exceeded error, and the caller will retry, with an exponential backoff, for the ScheduleToClose duration for the overall Nexus Operation.
This has a default and maximum as defined below in [Nexus Operation duration limits](/cloud/limits#nexus-operation-duration-limits).

### Nexus Operation duration limits {#nexus-operation-duration-limits}

Each Nexus Operation has a maximum ScheduleToClose duration of 60 days.
This is most applicable to asynchronous Nexus Operations completed with an asynchronous callback using a separate Nexus request from the handler back to the caller Namespace.

For enhanced security, you may sign completion callbacks with a single-use token in the future, and the 60 day maximum allows you to rotate the asymmetric encryption keys used for completion callback request signing.

While the caller of a Nexus Operation can configure the ScheduleToClose duration to be shorter than 60 days, the maximum duration can not extend beyond 60 days and capped by the server to 60 days.
